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Abstract 


This specification describes extensions to definitions of TLVs used 
by the Optimized Link State Routing Protocol version 2 (OLSRv2) and 
the MANET Neighborhood Discovery Protocol (NHDP) to increase their 
abilities to accommodate protocol extensions. This document updates 
RFC 7181 (OLSRv2) and RFC 6130 (NHDP). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7188. 
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Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the 
Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] 
are protocols for use in Mobile Ad Hoc Networks (MANETs) [RFC2501], 
based on the Generalized MANET Packet/Message Format [RFC5444]. 


This document updates [RFC6130] and [RFC7181], specifically their use 
of TLV (Type-Length-Value) elements, to increase the extensibility of 
these protocols and to enable some improvements in their 
implementation. 


This specification reduces the latitude of implementations of 
[RFC6130] and [RFC7181] to consider some messages, which will not be 
created by implementations simply following those specifications, as 
a reason to consider the message as "badly formed", and thus as a 
reason to reject the message. This gives greater latitude to the 
creation of extensions of these protocols, in particular extensions 
that will interoperate with unextended implementations of those 
protocols. As part of that, it indicates how TLVs with unexpected 
value fields must be handled, and adds some additional options to 
those TLVs. 


Note that TLVs with unknown type or type extension are already 
specified as to be ignored by [RFC6130] and [RFC7181] and also are 
not a reason to reject a message. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


Additionally, this document uses the terminology of [RFC5444], 
[RFC6130], and [RFC7181]. 


Applicability Statement 


This document updates the specification of the protocols described in 
[RFC6130] and [RFC7181]. 


Specifically, this specification updates [RFC6130] and [RFC7181] in 
the following ways: 


o Removes the latitude of rejecting a message with a TLV with a 
known type, but with an unexpected TLV Value field, for the TLV 
Types defined in [RFC6130] and [RFC7181]. 
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o Specifies the handling of a TLV Value field with unexpected 
length. 


o Sets up IANA registries for TLV Values for the Address Block TLVs: 
* LOCAL_IF, defined in [RFC6130]. 
*  LINK_STATUS, defined in [RFC6130]. 
*  OTHER_NEIGHB, defined in [RFC6130]. 
* MPR, defined in [RFC7181], now considered as a bit field. 


* NBR_ADDR_TYPE, defined in [RFC7181], now considered as a bit 
field. 


o Defines a well-known TLV Value for "UNSPECIFIED" for the Address 
Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all 
defined in [RFC6130]. 


4. TLV Values 


NHDP [RFC6130] and OLSRv2 [RFC7181] define a number of TLVs within 
the framework of [RFC5444]. These TLVs define the meaning of only 
some of the contents that can be found in a TLV Value field. This 
limitation may be either defining only certain TLV Values or 
considering only some lengths of the TLV Value fields (or a single- 
value field in a multivalue Address-Block TLV). This specification 
describes how NHDP [RFC6130] and OLSRv2 [RFC7181] are to handle TLVs 
with other TLV Value fields. 


4.1. Unrecognized TLV Values 


NHDP and OLSRv2 specify that, in addition to well-defined reasons (in 
the respective protocol specifications), an implementation of these 
protocols MAY recognize a message as "badly formed" and therefore 
"invalid for processing" for other reasons (Section 12.1 of [RFC6130] 
and Section 16.3.1 of [RFC7181]). These sections could be 
interpreted as allowing rejection of a message because a TLV Value 
field is unrecognized. This specification removes that latitude: 


o An implementation MUST NOT reject a message because it contains an 
unrecognized TLV value. Instead, any unrecognized TLV Value field 
MUST be processed or ignored by an unextended implementation of 
NHDP or OLSRv2, as described in the following sections. 


o Hence, this specification removes the 7th, 10th, and 11th bullets 
in Section 12.1 of [RFC6130]. 
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It should be stressed that this is not a change to [RFC6130] or 
[RFC7181], except with regard to not allowing this to be a reason for 
rejection of a message. [RFC6130] or [RFC7181] are specified in 
terms such as "if an address is associated with a value of LOST by a 
LINK_STATUS TLV". Association with an unrecognized value has no 
effect on any implementation strictly following such a specification. 


4.2. TLV Value Lengths 


The TLVs specified in [RFC6130] and [RFC7181] may be either single- 


value or multivalue TLVs. In either case, the length of each item of 
information encoded in the TLV Value field is the "single-length", 
defined and calculated as in Section 5.4.1 of [RFC5444]. All TLVs 


specified in [RFC6130] and [RFC7181] have a one- or two-octet single- 
length. These are considered the expected single-lengths of such a 
received TLV. 


Other single-length TLV Value fields may be introduced by extensions 
to [RFC6130] and [RFC7181]. This document specifies how 
implementations of [RFC6130] and [RFC7181], or extensions thereof, 
MUST behave on receiving TLVs of the TLV types defined in [RFC6130] 
and [RFC7181], but with TLV Value fields with other single-length 
values. 


The following principles apply: 


o If the received single-length is greater than the expected single- 
length, then the excess octets MUST be ignored. 


o If the received single-length is less than the expected single- 
length, then the absent octets MUST be considered to have all bits 
cleared (0). 


Exception: 


o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be 
considered an error. 


4.3. Undefined TLV Values 


[RFC6130] and [RFC7181] define a number of TLVs, but for some of 
these TLVs they specify meanings for only some TLV Values. This 
document establishes IANA registries for these TLV Values, with 
initial registrations reflecting those used by [RFC6130] and 
[RFC7181], and as specified in Section 4.3.3. 


There are different cases of TLV Values with different 
characteristics. These cases are considered in this section. 
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4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB 


For the Address-Block TLVs LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB 
TLVs, defined in [RFC6130], only a limited number of values are 
specified for each. These are converted, by this specification, into 
extensible registries with initial registrations for values defined 
and used by [RFC6130] -- see Section 5. 


An implementation of [RFC6130] that receives a LOCAL_IF, LINK_STATUS, 
or OTHER_NEIGHB TLV with any TLV Value other than the values that are 
defined in [RFC6130] MUST ignore that TLV Value, as well as any 
corresponding attribute association to the address. 


4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE 


The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [RFC7181], 
are similar to those defined in [RFC6130] in having only limited 
values specified (1, 2, and 3): 1 and 2 represent the presence of two 
different attributes associated to an address, and 3 represents "both 
1 and 2". 


These TLV Value fields are, by this specification, converted to bit 
fields and MUST be interpreted as such. As the existing definitions 
of values 1, 2, and 3 behave in that manner, it is likely that this 
will involve no change to an implementation, but any test of (for 


example) Value = 1 or Value = 3 MUST be converted to a test of (for 
example) Value bitand 1 = 1, where "bitand" denotes a bitwise AND 
operation. 


This specification creates registries for recording reservations of 
the individual bits in these bit fields, with initial registrations 
for values defined and used by [RFC7181] -- see Section 5. 


Other TLVs defined by [RFC7181] are not affected by this 
specification. 


4.3.3. Unspecified TLV Values 


The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS, 
and OTHER_NEIGHB TLVs each include an additional TLV Value 
UNSPECIFIED. This TLV Value represents a defined value that, like 
currently undefined TLV Values, indicates that no information is 
associated with this address; the defined value will always have this 
meaning. Such a TLV Value may be used to enable the creation of more 
efficient multivalue Address Block TLVs or to simplify an 
implementation. 
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The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is 
already satisfied by the TLV Value zero, provided that each bit in 
the TLV Value is defined as set (’1’) when indicating the presence of 
an attribute, or clear (’0’) when indicating the absence of an 
attribute. Therefore, this is required for registrations from the 
relevant registries; see Section 5. 


For the LINK_METRIC TLV, this is already possible by clearing the 
most significant bits (0 to 3) of the first octet of the TLV Value. 
It is RECOMMENDED that in this case the remaining bits of the TLV 
Value are either all clear (’0’) or all set (’1’). 
5. IANA Considerations 
IANA has completed the ten actions set out in the following sections. 
5.1. LOCAL_IF Address Block TLVs 


5.1.1. New Registry 


IANA has created a new sub-registry called "LOCAL_IF TLV Values" 
within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. 


IANA has populated this registry as specified in Table 1. 


+--------- +------------- +------------------------------- +----------- + 

| Value | Name | Description | Reference | 

+--------- +------------- +------------------------------- +----------- + 

| o | THIS_IF | The network address is | RFC 7188 

| | | associated with this local | 

| | | interface of the sending | 

| | | router | | 

| | | | | 
1 OTHER_IF The network address is RFC 7188 

| | | associated with another local | 

| | | interface of the sending | 

| | | router | | 

| | | | | 

| 2-223 | | Unassigned | | 

| 224-254 | | Reserved for Experimental Use RFC 7188 

| | 

| 255 | UNSPECIFIED | No information about this | RFC 7188 | 

| | | network address is provided | 

+--------- +------------- +------------------------------- +----------- + 


Table 1: LOCAL_IF TLV Values 
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New assignments are to be made by Expert Review [RFC5226]. 


The Designated Experts are required to use the guidelines specified 
in [RFC6130] and [RFC7181]. 


5.1.2. Modification to Existing Registry 


IANA maintains a sub-registry called "LOCAL_IF Address Block TLV Type 
Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" 
registry. This sub-registry already had an entry for value 0. IANA 
has replaced the entry in the Description column for this value with 
the text "This value is to be interpreted according to the registry 


LOCAL_IF TLV Values". The resulting table is as specified in 

Table 2. 

tesSSSsSsacS qe aaa eee nae oe ae ane aes eae Sees esaeass 4-—----------- + 

| Type | Description | Reference | 
Extension | | | 

+----------- Pe E E E Tarner e + 

| o | This value is to be interpreted | RFC 6130, 

| | according to the registry LOCAL_IF TLV | RFC 7188 | 

Values 
| 1-255 | Unassigned | 
P toee a a Toae === + 


Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications 
5.2. LINK_STATUS Address Block TLVs 
5.2.1. New Registry 


IANA has created a new sub-registry called "LINK_STATUS TLV Values" 
within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. 


IANA has populated this registry as specified in Table 3. 
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5 


2 


+ + 
| | 
+ + 
| The link on this interface | RFC 7188 
| from the router with that | 
| network address has been lost | 
| | 
SYMMETRIC | The link on this interface | RFC 7188 
from the router with that 
network address has the 
| status of symmetric | 
| | 
HEARD | The link on this interface | RFC 7188 
| from the router with that | 
| network address has the | 
| | 
| | 
| | 
| | 


status of heard 
Unassigned 
RFC 7188 


Reserved for Experimental Use 


No information about this RFC 7188 


network address is provided 


UNSPECIFIED 


Table 3: LINK_STATUS TLV Values 
New assignments are to be made by Expert Review [RFC5226]. 


The Designated Experts are required to use the guidelines specified 
in [RFC6130] and [RFC7181]. 


-2. Modification to Existing Registry 
IANA maintains a sub-registry called "LINK_STATUS Address Block TLV 


Type Extensions" within the "Mobile Ad hoc NETwork (MANET) 
Parameters" registry. This sub-registry already had an entry for 


value 0. IANA has replaced the entry in the Description column for 
this value with the text "This value is to be interpreted according 
to the registry LINK_STATUS TLV Values". The resulting table is as 


specified in Table 4. 
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+----------- + 
| Type | Descriptio 
| Extension | 
+----------- + 
| 0 | 
| | 
| | TLV Values 
| | 
| 1-255 | Unassigned 
+----------- + 


This value is to be interpreted 
according to the registry LINK_STATUS 


+ ————— + —— + 


April 2014 
Serena + 
Reference | 

| 
E + 
RFC 6130, | 
RFC 7188 | 
| 
| 
| 
SoS SSeS + 


Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications 


5.3. OTHER_NEIGHB Address Block TLVs 


5.3.1. Create New Registry 


IANA has created a new sub-registry called "OTHER_NEIGHB TLV Values" 
within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. 


IANA has populated this registry as specified in Table 5. 


4+--------- 4+------------- 
| Value | Name 
4+--------- 4------------- 
| o | LOST 

| | 

E: | SYMMETRIC 

| | 

| | 

| | 

| 2-223 | 

| 224-254 | 

| | 

| 255 | UNSPECIFIED 
| | 

4+--------- 4+------------- 


Table 5: OTHE 


+ 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


R. 


The neighbor relationship 
with the router with that 
network address has been lost 


The neighbor relationship 
with the router with that 
network address is symmetric 
Unassigned 


Reserved for Experimental Use 


No information about this 
network address is provided 


NEIGHB Address Block TLV Value 


+ 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


S 


New assignments are to be made by Expert Review [RFC5226]. 


The Designated Experts are required to use the guidelines 
in [RFC6130] and [RFC7181]. 
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----------- + 
Reference | 
----------- + 
RFC 7188 | 
| 
RFC 7188 | 
| 
| 
RFC 7188 | 
| 
RFC 7188 | 
| 
----------- + 
specified 
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5.3.2. Modification to Existing Registry 


April 2014 


IANA maintains a sub-registry called "OTHER_NEIGHB Address Block TLV 


Type Extensions" within the "Mobile Ad hoc NETwork 


Parameters" registry. This sub-registry already had an entry for 


value 0 


this value with the text 
to the registry OTHER_NEIGHB TLV Values". 


(MANET ) 


. IANA has replaced the entry in the Description column for 


specified in Table 6. 


Table 6 


Se POSS Sas SS Se Se Se ce Set esa See SSeS e test 
| Description | 
sion | | 
ee thes Se See ee ee oe eee ee Saat 
| This value is to be interpreted 
according to the registry OTHER_NEIGHB 
TLV Values | 
| 
| Unassigned | 
EEE T E E E 


"This value is to be interpreted according 
The resulting table is as 


SOES + 
Reference | 

| 
ee GE + 
RFC 6130, | 
RFC 7188 

| 

| 
e + 


: OTHER_NEIGHB Address Block TLV Type Extensions Modifications 


5.4. MPR Address Block TLVs 


5.4.1. New Registry 


IANA has created a new sub-registry called "MPR TLV Bit Values" 
the "Mobile Ad hoc NETwork (MANET) Parameters" registry. 


within 


IANA has populated this registry as specified in Table 7. 


+ 
| 

+ 
| 
| 
| 
| 
| 
| 

+ 


0x02 


4+---------- + 
| Name | 
4+---------- + 
| Flooding | 
| | 
| | 
| | 
| Routing 

| | 
| | 
| | 
4+---------- + 


Table 7: MPR 


Dearlove & Clausen 


The neighbor with that 
network address has been 
selected as flooding MPR 


The neighbor with that 
network address has been 


selected as routing MPR 


Unassigned 


Address Block TLV Bit Values 


Standards Track 


+ — + 


Bea ereaes= + 
Reference | 
SEE E + 
RFC 7188 | 
| 
| 
| 
RFC 7188 
| 
| 
| 
ITER + 
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New assignments are to be made by Expert Review [RFC5226]. 


The Designated Experts are required to use the guidelines specified 
in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are 
required to ensure that the following sense is preserved: 


o For each bit in the field, a set bit (1) means that the address 
has the designated property, while an unset bit (0) means that no 
information about the designated property is provided. In 
particular, an unset bit must not be used to convey any specific 
information about the designated property. 


5.4.2. Modification to Existing Registry 


IANA maintains a sub-registry called "MPR Address Block TLV Type 
Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" 
registry. This sub-registry already had an entry for value 0. IANA 
has replaced the entry in the Description column for this value with 
the text "This value is to be interpreted according to the registry 


MPR TLV Bit Values". The resulting table is as specified in Table 8. 
+----------- +----------------------------------------- +------------- + 
| Type | Description | Reference | 
| Extension | | | 
+----------- +----------------------------------------- +------------- + 
| o | This value is to be interpreted | RFC 7181, 

| | according to the registry MPR TLV Bit | RFC 7188 | 

Values 
| 1-255 | Unassigned | 
+----------- +----------------------------------------- +------------- + 


Table 8: MPR Address Block TLV Type Extensions Modifications 


5.5. NBR_ADDR_TYPE Address Block TLVs 
5.5.1. New Registry 


IANA has created a new sub-registry called "NBR_ADDR_TYPE Address 
Block TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET) 
Parameters" registry. 


IANA has populated this registry as specified in Table 9. 
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dare earn + 
Reference | 


ORIGINATOR The network address is an RFC 7188 

originator address 

reachable via the 

originating router 

0x02 ROUTABLE The network address is a RFC 7188 
routable address reachable 


via the originating router 


Unassigned 


+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 

+ 


+ — 
+ — 


----------- + 
Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values 
New assignments are to be made by Expert Review [RFC5226]. 


The Designated Experts are required to use the guidelines specified 
in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are 
required to ensure that the following sense is preserved: 


o For each bit in the field, a set bit (1) means that the address 
has the designated property, while an unset bit (0) means that no 
information about the designated property is provided. In 
particular, an unset bit must not be used to convey any specific 
information about the designated property. 


5.5.2. Modification to Existing Registry 
IANA maintains a sub-registry called "NBR_ADDR_TYPE Address Block TLV 


Type Extensions" within the "Mobile Ad hoc NETwork (MANET) 
Parameters" registry. This sub-registry already had an entry for 


value 0. IANA has replaced the entry in the Description column for 
this value with the text "This value is to be interpreted according 
to the registry NBR_ADDR_TYPE TLV Bit Values". The resulting table 


is as specified in Table 10. 
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+----------- +------------------------ - = = 5 = +----------- + 
| Type | Description | Reference | 
| Extension | | | 
+----------- +------------------------- = = +----------- + 
| o | This value is to be interpreted according | RFC 7181, | 
| | to the registry NBR_ADDR_TYPE Address | RFC 7188 | 
| | Block TLV Bit Values | | 
| | | | 
| 1-255 | Unassigned | 

+----------- +------------------------ - = +----------- + 

Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions 
Modifications 
6. Security Considerations 


The updates made to [RFC6130] and [RFC7181] have the following 
implications on the security considerations: 


o Created IANA registries for retaining TLV values for TLVs, already 
defined in the already published specifications of the two 
protocols, and with initial registrations for the TLV values 
defined by these specifications. This does not give rise to any 
additional security considerations. 


o Enabled protocol extensions for registering TLV values in the 
created IANA registries. Such extensions MUST specify appropriate 
security considerations. 


o Created, in some registries, a registration for "UNSPECIFIED" 
values for more efficient use of multivalue Address Block TLVs. 
The interpretation of an address being associated with a TLV of a 
given type and with the value "UNSPECIFIED" is identical to that 
address not being associated with a TLV of that type. Thus, this 
update does not give rise to any additional security 
considerations. 


o Reduced the latitude of implementations of the two protocols to 
reject a message as "badly formed" due to the value field of a TLV 
being unexpected. These protocols are specified in terms such as 
"if an address is associated with a value of LOST by a LINK_STATUS 
TLV". Association with an unknown value (or a value newly defined 
to mean no link status information) has no effect on such a 
specification. Thus, this update does not give rise to any 
additional security considerations. 
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o Did not introduce any opportunities for attacks on the protocols 
through signal modification that are not already present in the 
two protocols. 
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